1. Field of the Invention
The present invention relates generally to an intelligent electronic device (IED), such as used by commercial, industrial, or residential customers of power utility companies and, more particularly, to methods and systems for providing easy access to an internal IED file structure.
2. Description of the Related Art
The Modbus protocol defines a message structure that controllers, such as personal computers, recognize and use, regardless of the type of networks over which they communicate. Modbus (and protocols in general) describes the process a controller uses to request access to a device, how it will respond to requests from devices and how errors will be detected and reported. Characteristically, the Modbus protocol establishes a common format for the layout and content of message fields. During communication with Modbus compatible devices, the protocol determines how each controller knows its device address, recognizes a message addressed to it, determines the kind of action to be taken and how the controller will extract any data or other information contained in the message. If a reply is required, the controller constructs a reply message and will transmit it using the Modbus protocol.
There are many reasons for using Modbus protocol over other protocols for communications between IED equipment. Some of the main reasons for the extensive use of Modbus over other communications protocols are threefold. First, it is openly published and royalty-free. Second, it is a relatively easy industrial network to deploy because it is well understood and supported by many commercial and non-commercial entities and pieces of equipment in the industry. Third, it moves raw bits or words without placing many restrictions on vendors. Modbus allows for communication between many devices connected to the same network, for example, a system that measures temperature and humidity and communicates the results to a computer. Modbus is often used to connect a supervisory computer with a remote terminal unit (RTU) in supervisory control and data acquisition (SCADA) systems.
The Modbus communication interface is built around messages. The format of these Modbus messages is independent of the type of physical interface used. For example, the same message is used on RS232 as on Modbus/TCP over Ethernet. In other words, the same basic protocol can be used regardless of the connection type or medium. A device can also communicate with several Modbus nodes, even if they are connected with different interface types, without the need to use a different protocol for every connection.
On simple interfaces like RS485 or RS232, the Modbus messages are sent without encapsulation over the network. In this case, the network is dedicated to Modbus. When using more versatile network systems like TCP/IP over Ethernet, the Modbus messages are embedded in a Modbus TCP wrapper which forms TCP/IP packets of Modbus messages. The format of Modbus TCP messages is simplified because of the robust error detection which is built into the TCP/IP protocol and is built into the Ethernet to provide error free transmissions so that the checksum which is normally part of the Modbus message in not needed. In addition, current Ethernet based networks have embedded hardware which does the error checking providing additional performance benefits. In the case of an Ethernet network, Modbus and other protocols and types of connections can co-exist at the same physical interface at the same time. The main Modbus message structure is a master (client)/slave (server) implementation which is able to function on both point-to-point and multidrop networks. The extension to Modbus TCP extends Modbus messaging to work over additional network configurations such as star, star-bus and star-ring topologies.
Standard Modbus ports use an RS-232 compatible serial interface that defines connector pin outs, cabling, signal levels, transmission baud rates and parity checking.
The Modbus protocol is a non-file centric packet protocol and each Modbus message in the protocol has the same structure. Rather than files, one of its sets of commands operates on registers, a register being a unit of information conveying 65,536 different values, i.e., a 2 byte quantity.
Four basic elements are present in each Modbus message. The sequence of these elements is the same for all messages, to make it easy to parse the content of the Modbus message. A conversation is always started by a master in the Modbus network. A Modbus master sends a message and—depending on the contents of the message—a slave takes action and responds to it.
FIG. 1. illustrates the packet structure of a Modbus message comprising a message header, including device address information, and the like, and a data field which comprises messages, data, commands and particularly register definitions of address devices for which the queries, commands and messages are directed. The device address information refers to the address of the receiver. This parameter contains one byte of information. In Modbus/ASCII, it is coded with two hexadecimal characters, in Modbus/RTU, one byte is used. Valid addresses are in the range 0 . . . 247. The values 1 . . . 247 are assigned to individual Modbus devices and 0 is used as a broadcast address. Messages sent to the latter address will be accepted by all slaves. A slave always responds to a Modbus message. When responding, it uses the same address as the master in the request. In this way, the master can see that the device is actually responding to the request.
The second parameter in each Modbus message is the function code. This defines the message type and the type of action required by the slave. The parameter contains one byte of information. In Modbus/ASCII, this is coded with two hexadecimal characters, in Modbus/RTU, one byte is used. Valid function codes are in the range 1 . . . 255. Not all Modbus devices recognize the same set of function codes.
When a slave receives a Modbus query message with function 01, the slave collects the necessary output values and constructs a response message. The length of this message is dependent on the number of values that have to be returned. In general, when N values are requested, a number of ((N+7) mod 8) bytes are necessary to store these values. The actual number of databytes in the datablock is put in the first byte of the data field.
An exemplary Modbus field content diagram is given in FIG. 2. In the Modbus exemplar of FIG. 2, Modbus message is structured to identify a communication partner by its “slave address” and define the function code for the action desired. For example, and in accordance with an exemplary Modbus query set forth in FIG. 3, a “read holding registers” request might be made to slave device address 06, requesting data from holding registers 40108, 40109, and 40110. All that is required, therefore, is to understand how a protocol message is structured and be able to determine how to populate the various fields of the message.
One pioneer IED system that incorporated features for downloading log data, via Modbus was the Nexus 1250™ meter, manufactured by Electro Industries of Long Island, N.Y. The approach for downloading log data in the Nexus 1250™ meter was to use standard Modbus commands to read a 4 Mbyte memory. However, a drawback of implementing the Modbus protocol to retrieve log data on the order of 4 Mbytes is that it cannot efficiently support large data downloads. That is, the master/slave structure imposed by Modbus results in a limited message size. More particularly, the limitations imposed by the Modbus protocol are two-fold. First, the addressing capabilities of the Modbus protocol restrict the addressing register to two bytes which imposes an upper limit of 64 k addressing capability. Secondly, the Modbus answer structure to a query provides the number of data bytes in the response in Byte 3 as a one byte number. Therefore, the number of bytes can not be greater than the largest number specified by a one byte number which is 256 bytes. Similarly, the number of bytes to be written are also limited to 256 bytes. These message size limitations imposed by the Modbus protocol result in performance issues. This unfortunately necessitates an excessively large number of messages to download large data files. For example, to retrieve a 1 megabyte Log file (i.e., 1,048,576 bytes), which has been recorded by the IED using Modbus RTU, would take 1048576/254=4096 Modbus transfers. This is problematic in that each Modbus transfer requires a query and a response message to be sent. In addition, before the IED can respond, the IED must also wait for a “dead time” when the slave is not receiving any further characters. The wait time or “dead time” is used to indicate to the slave that the message it was sent is complete. This time period is defined by the Modbus specification. The IED then has to process the query and send the response. The master is prohibited from making its next query until receiving a response from the slave so it is stalled until receiving a response. By increasing the amount of data sent for each query will therefore greatly increase the performance because it will reduce the amount messages that are sent and make the message processing by the master and slave more efficient.
Among other patentable inventions disclosed in this application, a need therefore exists at least for a system and method capable of providing easy access to the internal file structure of an IED, not presently defined or supported directly by legacy protocols used in industry, such as the Modbus protocol.